## Issue description
`specs/IR-0001/spec.md` (DECISION-02) and `specs/IR-0001/wave-plan.md` (W2-C1/W2-C5) disagree on whether the holdout repository is public or private.

This is a spec-level contract contradiction that will cause downstream implementation to diverge (App installation strategy, credential scope, where failure details are written, and what “no leakage” means).

## Issue Context
- `DECISION-02` explicitly states the holdout repo is public.
- The wave plan explicitly describes a private holdout repo and treats it as the only exception to an “all public” policy.

## Fix Focus Areas
- specs/IR-0001/spec.md[121-122]
- specs/IR-0001/wave-plan.md[31-35]

## Expected change
Pick one posture (public or private) and update BOTH documents to match, including any dependent text (e.g., where failure details live, how isolation is achieved, and which credential/App model is used).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

## Issue description
`spec.md` frontmatter sets `apiDelta.file: specs/IR-0001/api-delta.md`, but the referenced artifact is not included in this PR.

This makes the spec internally inconsistent: it declares a public API delta deliverable that does not exist.

## Issue Context
The PR description states it only contains two artifacts, but the spec frontmatter points to a third required artifact.

## Fix Focus Areas
- specs/IR-0001/spec.md[63-70]

## Expected change
Do one of:
1) Add `specs/IR-0001/api-delta.md` (even a minimal stub) matching the declared path, or
2) Remove/adjust the `apiDelta` frontmatter to not reference a non-existent file.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

## Issue description
`DECISION-01` states that an ADR draft exists at `specs/IR-0001/ADR-draft-ar3-phase1-direct-api.md`, but the file is not included in this PR.

This leaves the spec asserting compliance work that isn’t actually present, undermining the decision’s auditability.

## Issue Context
The decision text uses the existence of the draft as part of the justification/plan (“草案随本 spec …”). If it’s not actually shipped, readers cannot review it.

## Fix Focus Areas
- specs/IR-0001/spec.md[118-121]

## Expected change
Do one of:
1) Add the referenced ADR draft file at the exact path mentioned, or
2) Edit DECISION-01 to remove the claim that the draft is included here (and instead reference where it will live / the tracked work item / the target PR).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

🏁 Script executed:

sed -n '1,80p' specs/IR-0001/ADR-draft-ar3-phase1-direct-api.md

Repository: Cloudbird-Software/.github

Length of output: 1616

🌐 Web query:

LiteLLM Proxy virtual keys multi-tenant spend management rate limits official documentation

💡 Result:

LiteLLM Proxy supports multi-tenant spend management and rate limiting through Virtual Keys and a hierarchical architecture [1][2]. To utilize these features, you must deploy the proxy with a supported database (e.g., PostgreSQL) [3][4]. Key concepts and implementation details: Virtual Keys and Multi-Tenancy Virtual Keys act as the authentication layer that links requests to specific users or teams for cost tracking and policy enforcement [1][2]. Teams provide the primary tenant boundary [1]. You can define organizations, teams, and users in a hierarchy where spend and limits flow downward [1]. A request's cost is attributed to the key, user, team, and organization simultaneously [1]. Spend Management Budgets are enforced at the Key, User, and Team levels [2]. The proxy enforces budgets by checking spend against data stored in the database [5]. If a deployment is database-less, these budget features are unavailable [5]. Budgets are hierarchical: a team budget cannot exceed its organization's budget, and a user budget cannot exceed the team's [1]. A request is blocked if any level along its hierarchy exceeds its budget [1]. You can set budgets (e.g., max_budget, budget_duration) when creating or updating teams and keys via management endpoints like /team/new or /key/generate [3][6]. Rate Limiting Rate limits (TPM/RPM) can be applied per key, user, or team [5][2]. You can set TPM (tokens per minute) and RPM (requests per minute) limits on virtual keys [3][5]. For teams, you can set per-model rate limits that apply to all keys belonging to that team [6]. The proxy also supports Dynamic TPM/RPM Allocation, allowing you to reserve model capacity for specific priority levels [7]. Automation For multi-tenant environments, you can use JWT-to-Virtual Key mapping [8]. This allows you to automatically provision virtual keys and assign them to teams/users based on JWT claims (e.g., client_id), providing granular control without manual key generation [9][8]. Documentation References - For virtual key management and generation: [3][4] - For team budgets and hierarchical enforcement: [1][6] - For rate limiting configurations: [5][7] - For multi-tenant architecture and identity provisioning: [1][9]

Citations:

• 1: https://docs.litellm.ai/docs/proxy/multi_tenant_architecture
• 2: https://deepwiki.com/BerriAI/litellm/3.5.1-api-key-management
• 3: https://docs.litellm.ai/docs/proxy/virtual_keys
• 4: https://github.com/BerriAI/litellm/blob/main/docs/my-website/docs/proxy/virtual_keys.md
• 5: https://docs.litellm.ai/docs/proxy/users
• 6: https://docs.litellm.ai/docs/proxy/team_budgets
• 7: https://docs.litellm.ai/docs/proxy/dynamic_rate_limit
• 8: https://docs.litellm.ai/docs/proxy/jwt_key_mapping
• 9: https://docs.litellm.ai/docs/proxy/identity_provisioning

🌐 Web query:

Cloudflare AI Gateway spend limit team user application BYOK budget rate limits official documentation

💡 Result:

Cloudflare AI Gateway provides distinct features for managing costs and traffic, specifically through spend limits and rate limiting [1][2]. Spend Limits Spend limits allow you to set cost-based budgets in dollars rather than just counting requests [1][2]. - Functionality: These limits track cumulative spend in real time based on token usage and model pricing [1]. They function independently of traditional rate limiting [2]. - Configuration: You can define up to 20 spend limit rules per gateway via the dashboard or API [1]. Rules use rolling or fixed time windows (e.g., daily, weekly, monthly) [2]. - Scoping: Limits can be scoped by model, provider, or custom metadata dimensions such as user ID, team, or application [1][2]. To use these custom dimensions, your application must pass the relevant metadata in requests [1][2]. - Enforcement: When a limit is reached, AI Gateway returns a 429 Too Many Requests response [1]. By default, requests are blocked, but you can configure dynamic routes to fall back to a cheaper model instead [1][2]. - Compatibility: Spend limits apply to both Unified Billing and BYOK (Bring Your Own Keys) requests, provided the model has known pricing [1][3]. Rate Limiting Rate limiting manages traffic volume by restricting the number of requests within a specified time window [4]. - Functionality: It is a request-count-based mechanism that helps prevent spikes and suspicious activity [4]. - Limits: There is a specific system-level rate limit for Unified Billing requests, currently 200 requests per 60 seconds per gateway [5]. This system limit does not apply to BYOK requests [5]. BYOK (Bring Your Own Keys) BYOK allows you to store your own provider API keys securely in the Cloudflare dashboard [6]. - Management: It eliminates the need for hardcoded keys in your application and simplifies key rotation [6]. - Relation to limits: You can apply rate limits and spend limits to BYOK-configured gateways [6]. Unlike Unified Billing, BYOK requests are not subject to the 200 requests/60s system rate limit [5]. Cost Tracking Note: Spend limit calculations are best-effort estimations based on token counts and model pricing [1][7]. For exact billing, always refer to your specific provider's dashboard [1][7]. If you have negotiated rates, you can override default pricing using the custom costs feature [8][7].

Citations:

• 1: https://developers.cloudflare.com/ai-gateway/features/spend-limits/
• 2: https://blog.cloudflare.com/ai-gateway-spend-limits/
• 3: https://developers.cloudflare.com/changelog/post/2026-06-05-spend-limits/
• 4: https://developers.cloudflare.com/ai-gateway/features/rate-limiting/
• 5: https://developers.cloudflare.com/ai-gateway/reference/limits/
• 6: https://developers.cloudflare.com/ai-gateway/configuration/bring-your-own-keys/
• 7: https://developers.cloudflare.com/ai-gateway/observability/costs/
• 8: https://developers.cloudflare.com/ai-gateway/features/

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- candidate files ---'
git ls-files | rg '(^|/)(agent\.schema\.yaml|models\.yaml|spec\.md)$|specs/IR-0001'
printf '%s\n' '--- relevant references ---'
rg -n -C 4 'IFACE-06|BUDGET-04|INV-07|DECISION-01|DECISION-02|model\.alias|registry/models\.yaml|pipeline/models\.yaml|gateway' \
  standards specs pipeline 2>/dev/null || true
printf '%s\n' '--- schema section ---'
sed -n '35,60p' standards/agent/agent.schema.yaml
printf '%s\n' '--- IR-0001 section map ---'
rg -n '^(#|##|###)|IFACE-06|BUDGET-04|INV-07|DECISION-01|DECISION-02' specs/IR-0001/spec.md

Repository: Cloudbird-Software/.github

Length of output: 14857

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- relevant specification context ---'
sed -n '70,125p' specs/IR-0001/spec.md
printf '%s\n' '--- ADR context ---'
sed -n '7,42p' specs/IR-0001/ADR-draft-ar3-phase1-direct-api.md
printf '%s\n' '--- all model and role references ---'
rg -n -C 2 '角色档|档 →|alias|family|models\.yaml|AR-8|spec-author|test-author|implementer|refactorer|judge-deep|coder-fast|reviewer' \
  --glob '*.md' --glob '*.yaml' --glob '*.yml' .

Repository: Cloudbird-Software/.github

Length of output: 21601

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- candidate files ---'
git ls-files | rg '(^|/)(specs/IR-0001/spec\.md|specs/IR-0001/ADR-draft-ar3-phase1-direct-api\.md|agent-registry/|.*README.*|.*\.ya?ml$)' | head -200
printf '%s\n' '--- relevant terms ---'
rg -n -i -C 3 'llm-gateway|DECISION-01|AR-3|ADR-draft-ar3-phase1-direct-api|PR objective|objective|IFACE-06|BUDGET-04|INV-07|holdout|App install|per-team|provider API' specs/IR-0001 agent-registry .github 2>/dev/null | head -300

Repository: Cloudbird-Software/.github

Length of output: 12260

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- AR-3 and related governance text ---'
rg -n -i -C 8 'AR-3|llm-gateway|gateway secret|provider key|LLM_API_KEY|ADR-0002' governance standards specs agent-registry 2>/dev/null | head -260
printf '%s\n' '--- ADR draft ---'
cat -n specs/IR-0001/ADR-draft-ar3-phase1-direct-api.md
printf '%s\n' '--- repository references to the stated PR objective ---'
rg -n -i -C 3 '使用既有|既有.*llm-gateway|use.*llm-gateway|existing.*llm-gateway|PR objective|objective' . 2>/dev/null | head -200
printf '%s\n' '--- agent-registry decision files ---'
git ls-files 'agent-registry/**' | head -100

Repository: Cloudbird-Software/.github

Length of output: 18633

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- spec excerpt ---'
sed -n '70,110p' specs/IR-0001/spec.md
printf '%s\n' '--- related references ---'
rg -n -C 3 'GitHub API|REST|GraphQL|outbound|出网|auto-merge|label|conductor|verdict|LLM|provider|网络|权限' specs/IR-0001
printf '%s\n' '--- workflow/action references ---'
rg -n -C 2 'conductor|verdict|auto-merge|gh api|github|label|merge' .github specs/IR-0001 2>/dev/null || true

Repository: Cloudbird-Software/.github

Length of output: 50382

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- tracked candidate files ---'
git ls-files | rg '(^|/)(specs/IR-0001|\.github/|.*workflow.*|.*action.*)'
printf '%s\n' '--- GitHub endpoint and permission declarations ---'
rg -n -i -C 3 'api\.github\.com|github\.com|permissions:|contents:|pull-requests:|issues:|actions:|checks:' specs/IR-0001 .github 2>/dev/null || true
printf '%s\n' '--- all relevant network/client references ---'
rg -n -i -C 2 'curl|wget|fetch|axios|requests|octokit|gh api|graphql|rest|provider|llm|openai|anthropic|egress|outbound|出网' specs/IR-0001 .github 2>/dev/null || true

Repository: Cloudbird-Software/.github

Length of output: 24341

🏁 Script executed:

#!/bin/bash
set -e
python3 - <<'PY'
from pathlib import Path
p = Path("specs/IR-0001/spec.md")
lines = p.read_text(encoding="utf-8").splitlines()
terms = ("出网", "GitHub API", "auto-merge", "label", "打开 PR", "LLM", "provider")
for i, line in enumerate(lines, 1):
    if any(t in line for t in terms):
        lo, hi = max(1, i-3), min(len(lines), i+3)
        print(f"--- lines {lo}-{hi} ---")
        for n in range(lo, hi+1):
            print(f"{n}: {lines[n-1]}")
PY

Repository: Cloudbird-Software/.github

Length of output: 13891

🏁 Script executed:

#!/bin/bash
set -e
echo '--- spec ---'
nl -ba specs/IR-0001/spec.md | sed -n '1,180p'
echo '--- related files ---'
git ls-files specs/IR-0001 .github
echo '--- relevant terms ---'
rg -n -i -C 3 '出网|GitHub API|api\.github\.com|auto-merge|label|pull request|LLM|provider|conductor|verdict|permissions|REST|GraphQL' specs/IR-0001 .github 2>/dev/null || true

Repository: Cloudbird-Software/.github

Length of output: 32582

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail
: "${ORG:?set ORG}"
: "${LOGIN:?set LOGIN}"
gh api "orgs/${ORG}/memberships/${LOGIN}" --jq '{state,role}'

Repository: Cloudbird-Software/.github

Length of output: 191

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

printf '%s\n' '--- spec context ---'
sed -n '80,105p' specs/IR-0001/spec.md

printf '%s\n' '--- related references ---'
rg -n -C 3 'INV-02|author_association|membership|组织管理员|owner|admin|state:\*' specs/IR-0001

printf '%s\n' '--- repository files mentioning the contract ---'
rg -n -C 2 'INV-02|author_association|orgs/.*/memberships|membership|GitHub App' .github specs || true

Repository: Cloudbird-Software/.github

Length of output: 16581

🌐 Web query:

site:docs.github.com REST organization memberships username state role author_association GitHub webhook payload

💡 Result:

In GitHub webhook payloads, the structure and availability of fields like username, state, role, and author_association vary depending on the specific event type and the context of the activity [1][2]. Membership-related events When an organization-level event involving membership occurs (such as a membership being added or removed), the payload typically includes a membership object [1][3]. This membership object describes the relationship between the user and the organization, including their state (e.g., active or pending) and their role (e.g., admin, member, or billing_manager) [1][4]. While the user initiating or affected by the action is represented in the payload, the specific field containing the username is typically found within a user object [5][6]. author_association The author_association field is generally not present in organization membership webhook payloads [1][7]. Instead, this field is common in event payloads related to repository activity, such as issue comments, pull request reviews, or discussions [5][8]. It indicates the permissions a user has in the repository where the event occurred, with common values including OWNER, COLLABORATOR, MEMBER, CONTRIBUTOR, and NONE [6][8]. General Payload Structure - Organization Object: Payloads triggered by organization webhooks or activity in organization-owned repositories include an organization object, which provides details about the organization itself [1][3]. - User Information: User details (such as login/username) are standard in most event payloads, typically nested within a user or sender object [5][6]. - Webhook Configuration: If you are using the REST API to configure organization webhooks, fields like username and password may be used for authentication/basic auth purposes within the webhook configuration (config) object, which is distinct from the event payload delivered to your server [9][10]. For authoritative details on specific events, always refer to the GitHub Webhook events and payloads documentation for the exact schema, as payloads are event-specific [1][2].

Citations:

• 1: https://docs.github.com/webhooks/webhook-events-and-payloads
• 2: https://docs.github.com/en/webhooks/types-of-webhooks
• 3: https://docs.github.com/en/enterprise-cloud@latest/webhooks/webhook-events-and-payloads
• 4: https://docs.github.com/en/rest/orgs/members
• 5: https://docs.github.com/en/rest/using-the-rest-api/issue-event-types?apiVersion=2026-03-10
• 6: https://docs.github.com/en/rest/issues/events
• 7: https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=requested
• 8: https://docs.github.com/en/rest/activity/events
• 9: https://docs.github.com/en/rest/orgs/webhooks
• 10: https://docs.github.com/en/rest/orgs/webhooks?apiVersion=2026-03-10

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

python3 - <<'PY'
from urllib.request import Request, urlopen
from html import unescape
import re

urls = {
    "membership": "https://docs.github.com/en/rest/orgs/members#get-an-organization-membership-for-a-user",
    "author_association": "https://docs.github.com/en/rest/repos/repos#list-repository-contributors",
}
for name, url in urls.items():
    req = Request(url, headers={"User-Agent": "read-only-doc-check"})
    with urlopen(req, timeout=20) as response:
        text = unescape(response.read().decode("utf-8", "ignore"))
    text = re.sub(r"<script.*?</script>|<style.*?</style>", " ", text, flags=re.S | re.I)
    text = re.sub(r"<[^>]+>", " ", text)
    text = re.sub(r"\s+", " ", text)
    terms = {
        "membership": ["state", "role", "admin", "member"],
        "author_association": ["author_association", "OWNER", "COLLABORATOR"],
    }[name]
    print(f"--- {name} ---")
    for term in terms:
        match = re.search(r".{0,180}" + re.escape(term) + r".{0,240}", text, re.I)
        print(f"{term}: {match.group(0) if match else 'NOT FOUND'}")
PY

Repository: Cloudbird-Software/.github

Length of output: 2451

🌐 Web query:

site:docs.github.com/en/rest/orgs/members "Get an organization membership for a user" "state" "role"

💡 Result:

To retrieve the organization membership of a specific user, including their state and role, you can use the GitHub REST API endpoint [1][2]. The endpoint requires a GET request to the following path: GET /orgs/{org}/memberships/{username} [1][2] In this request: {org} is the handle of the organization [1][2]. {username} is the handle of the user [1][2]. The response includes both the state and the role of the user within the organization [1][2]: - The state field indicates if the membership is active or pending [1][2]. - The role field specifies if the user is an admin, member, or billing_manager [1][2]. Note that to successfully access this information, the authenticated user making the API call must already be a member of the organization [1][2].

Citations:

• 1: https://docs.github.com/en/rest/orgs/members
• 2: https://docs.github.com/en/rest/orgs/members?apiVersion=2022-11-28

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail
rg -n -C 4 'concurrency:|cancel-in-progress:|queue:' --glob '*.yml' --glob '*.yaml' .

Repository: Cloudbird-Software/.github

Length of output: 164

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

printf '%s\n' '--- candidate files ---'
git ls-files 'specs/IR-0001/*' '.github/workflows/*' '*.yml' '*.yaml' | sed -n '1,160p'

printf '%s\n' '--- spec around INV-09 and related requirements ---'
sed -n '70,125p' specs/IR-0001/spec.md

printf '%s\n' '--- all BEH-10 and concurrency references ---'
rg -n -C 5 'BEH-10|INV-09|concurrency|cancel-in-progress|事件|重放|inbox|队列' specs/IR-0001 .github 2>/dev/null || true

printf '%s\n' '--- wave plan references ---'
if test -f specs/IR-0001/wave-plan.md; then
  sed -n '1,220p' specs/IR-0001/wave-plan.md
fi

Repository: Cloudbird-Software/.github

Length of output: 21109

🌐 Web query:

site:docs.github.com Actions concurrency group at most one running and one pending replacement cancel-in-progress false

💡 Result:

In GitHub Actions, when you define a concurrency group, the system ensures that at most one job or workflow in that group runs at a time [1][2]. When cancel-in-progress is set to false (which is the default behavior if not specified) [3][4], the following logic applies: 1. Running Job: If a job or workflow is already running in the concurrency group, any new job or workflow that is triggered will be placed in a pending state [1][2]. 2. Pending Queue: By default, the system allows at most one job or workflow to be in a pending state [1][5]. If a new job is queued while another is already pending, the existing pending job is canceled, and the newest job takes its place in the pending slot [1][2]. 3. Execution: Once the currently running job completes, the job in the pending state will start [1][2]. To allow more than one job to be queued and wait in the pending state, you can use the queue property set to max (which supports up to 100 pending runs) [1][6]. However, note that queue: max cannot be used in combination with cancel-in-progress: true, as these settings represent conflicting strategies for handling concurrent runs [2][6].

Citations:

• 1: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency
• 2: https://docs.github.com/actions/writing-workflows/choosing-what-your-workflow-does/control-the-concurrency-of-workflows-and-jobs
• 3: https://docs.github.com/en/enterprise-server@3.18/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency
• 4: https://docs.github.com/en/enterprise-server@3.8/actions/using-jobs/using-concurrency
• 5: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
• 6: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions